Various methods have attempted to authenticate, validate, securitize, and provide computational masking techniques to prevent undesired access to communications and communication signals, many with limited success. Most online transactions, for instance, are considered secure with assurances provided by the service providers employed to protect users' data and privacy. Unfortunately, in many if not all cases, these communications are protected with information private to a user and stored by a third-party. Continuous news regarding compromised private data, previously considered to be secure, has sparked new awareness of data vulnerability in the private, public, industrial and government sectors. In just the last year, global companies including Facebook, Equifax, Delta Airlines, Amazon and others have admitted to having data breaches which are affecting daily operations and their respective stock values.
The problem of securely storing and managing personal and private information today requires the users of personal computers and smart phones to install and run special purpose client applications specifically designed for such task. Exemplary programs are software products known as password managers such as those provided by Lastpass, Dashlane, Roboform, and 1Password. The operation of these commercial products typically requires users to authenticate themselves before they are granted access to information, data or services that are either financially relevant or confidential in nature. In other words, these products operate on the assumption that users are effectively and securely authenticated before access to the stored data is provided.
The most common, simple, and convenient form of authentication is based on the use of a static (i.e. fixed in time) credential (e.g. a password) which the user must provide to the application each time it is executed. In these scenarios, the security of all the stored data completely relies on the secrecy of the authentication credential. This is the only factor guarding against illegitimate usage by unauthorized individuals. The need to remember only one password to access all the data stored by password managers and the pivotal role this requirement plays in securing the private data is demonstrated by the customary appellation of a master password. One main argument in favor of using password managers requiring one single static master password is clearly and simply convenience, whereby the user can access all passwords anytime and anywhere as long as the user remembers just one single secret or confidential credential.
In the case where passwords are to be shared between devices, vendors of software password managers have developed and deployed computer cloud-based services designed to support synchronization requirements of users. Typically, such service requires the payment of a yearly fee and the servers store and retrieve from the cloud the latest password database that has been previously copied in encrypted format over the Internet from any of the installed database instances of the client application. When properly implemented by the vendors, this method can allow satisfying both the synchronization requirement as well as the need to provide an updated backup of the latest password database that can later be used for recovery purposes.
Summarizing, from the above description, the typical method employed for operation of software password managers is that users can install the client application on any of their digital platforms (laptop, PC, smart phone, etc.) and remain confident that by remembering only the master password they will be granted access to the latest version of the password database. This method works as long as they are connected to the Internet/an intranet such as the World Wide Web or an abbreviated version thereof.
The critical enabling underlying factors while employing software password managers are that users must: (1) rely on the confidentiality of the Master Password as the sole protection against unauthorized disclosure of all the contents of the password database. In other words, an attacker capable of sniffing or obtaining in other fraudulent way the master password can in principle and in practice gain access to all other passwords kept in the password database; (2) trust the product vendor and cloud service provider with the entire contents of the password database, albeit in encrypted format. In other words, notwithstanding all of the provided assurances, the user must release his most valuable data to a third party in the hope that it will be securely handled according to all the agreed and implied policies and procedures; and (3) accept the limitation of synchronizing the password database across computing platforms only when accessing Internet (i.e. while operating online). This requirement is at the root of the cloud as a service-for-fee and in some products (e.g. LastPass) and it is also extended to the case of one password database on a single platform (i.e. passwords are all stored on the cloud and cannot be accessed offline).
The three tenets of mainstream software password managers' usage described above, namely rely, trust, and accept, pose serious questions regarding the practical security and suitability of such products in today's real-life digital information management scenarios. In fact, the use of a static master password has been shown to be ineffective against social engineering, brute force guessing and malware driven attacks whereby a third party is capable of obtaining the password for reading any amount of the private stored data before the legitimate user discovers the theft. Such attacks highlight the main weakness of static login credentials, i.e., the decoupling of the authentication credentials from the individual which they are purposing to authenticate. In this case, the simple knowledge of the password allows any individual to access the data that is only supposed to be accessed by the authenticated entity. In the case of password managers, the security threat can be even more effective than against web services which can stop providing the service when under attack. In fact, once attackers copy the local password databases they can perform brute force rounds to discover the Master Password (or equivalent confidential/secret key) without any limitation on the number of attempts.
The use of static login credentials for applications requiring strong security assurances such as password managers has, therefore, been strongly criticized by security professionals warning about the catastrophic consequences of a theft or an unauthorized disclosure of the master password.
To this end, having realized that this problem risks undermining the very foundations of their products' value proposition, vendors of software password managers have started advocating the adoption of small hardware devices as additional authentication means beyond the simple and sole master password.
There is also a general class of two-factor authentication methods which aim at binding the presence of the physical user to the requirements of the authorization procedure. The second factor in addition to the static credentials can be something that the user has (a physical device or a token external to the host device) or something that the user is (obtained using biometric sensors, e.g. via fingerprinting or iris scanning). Because of limitations due to the technology and to the still relatively high costs associated to mass deployments of biometric devices, the prevailing choice has until now been to provide users with small hardware tokens which the users must have and operate each time they request access to the password database and cloud service.
However, both the static master password and the two-factor authentication methods described above suffer from at least one fundamental weakness, i.e., the need to rely on an application (a software controlled process executed on the host device) to authorize the user and communicate with the cloud sever.
For example, the application executing on the host device may require to retrieve a password, in which case the cloud sever may generate a random session key, and then protect the session key in such a way that it can be obtained only with the user-specific secret key kept in the hardware device owned by the user. With this approach, it would seem that no one except the legitimate user could receive the data, since only the password manager application can access the secret key and the secret key can never leave the device safely kept and operated by the user.
However, this approach has a weakness in that a rogue application, developed by a malicious programmer and executed on the user's host device—or on the programmer's device through remote connection—can make an identical request to the cloud server after obtaining all the necessary authentication data from the unaware user. In fact, the objective of the rogue application is only to access the sensitive cloud resources and not to know or extract the user-specific secret key from the hardware device. To obtain its goal, the rogue application can simply make the same authentication request to the cloud server that the client application would do using the user-specific secret, and thus obtain access to the sensitive data on the server. In this example, there is nothing to differentiate from the cloud server point of view the password manager's authentication request from that of the rogue application. Once this latter approach has gained access to the service, it can in principle operate independently from the legitimate application and from any further user input.
Remarkably, the weakness described above applies to all user-based authentication methods, regardless of the enabling technology applied to generate and store the secret access credentials. In fact, the roots of this vulnerability rest in the need for all user-based authentication methods to rely on the trustworthiness of the applications employed to communicate with the cloud service providers.
It is therefore clear that the security of cloud-enabled transactions is first and foremost dependent on the ability to authenticate executable code running on a host device, an issue which falls into the more general category of software security. The goal of providing reliable and practicable means for remotely authenticating software applications has been the subject of U.S. Pat. No. 8,713,705B2 and will not be further discussed here. Suffice it to conclude, however, that the approach advocated by vendors of software password managers cannot claim to resolve, in any definitive way, the critical vulnerability tied to the user's authentication and authorization when employing a static Master Password, with or without additional “strong” authentication means.
The criticality mentioned above is clearly related to the catastrophic nature of the security failure which occurs once the authentication and authorization steps are bypassed by a malicious code or attacker, namely the exposure of the entire contents of the password database. Hence, it is highly desirable to improve prior methods for authorizing access to private information and data. The authentication process is inadequate and we have addressed this issue in the present application.
In addition, cryptographic methods to keep information shared among users, software, devices and the like, secure, are becoming more prevalent. Many judge just how secure a communication is by comparing which encryption algorithm is employed. Examples of encryption algorithms that are commercially used today include AES (Advanced Encryption Standard), Triple-DES (Data Encryption Standard), Blowfish, and RC4. Thus, the sheer number and variety of encryption methods provides questions regarding which encryption is best and how much encryption is enough.
Unfortunately, encryption alone does not ensure security and more importantly, privacy. Data that travels over “free and open” communication mediums such as cell phones and internet communications paths are perfect targets for interception. Many individuals and organizations believe (with a false sense of security) upon the pretense of their data being encrypted. Normally, encrypting the data with a pre-existing algorithm simply means that an equally outstanding algorithm is required to decrypt. Conversely, an easier method to decrypt exists: keys. Much like the keys to a home, the strength of the encryption over these insecure “free and open” communication media are only as good as the keys and the algorithms that use the keys to unlock the data. Basically the principal is simple; find the proper key, and unlock the door.
Basically, two distinct encryption methods are widely used today: Symmetric and Asymmetric. Both are key-based algorithms. Which method is more secure is the subject of much debate.
Symmetric cryptography (also known as private-key, single-key, secret-key, shared-key, and one-key encryption) exchanges “secret-keys” that are identical (or related computationally) to encrypt and decrypt data between two or more users. Types of symmetric key ciphers include block ciphers that input blocks of plaintext and stream ciphers that input individual characters. Popular examples of block cipher methods include TripleDES (Data Encryption Standard) and AES (Advanced Encryption Standard). RC4 is an example of stream cipher.
For Symmetric Methods the advantages are simplicity and speed. Users only have to specify a single key to encrypt or decrypt data. Symmetric cryptography is also much more resistant to brute force attacks and requires less computational power than its counterpart asymmetric cryptography. One major issue involving the use of this method is that “secret keys” must be shared via a secret communication channel, which is the very purpose of sharing secret keys in the first place, thus presenting a “chicken-and-egg” situation. In addition, the origin and authenticity of a message cannot be guaranteed, since both users use the same key, leaving this method, like many other cryptographic methods, open to “man-in-the-middle” attacks. Lastly, communication with every new user requires a new key to be shared to prevent compromise of a “universal key”, thereby increasing the number of keys that have to be stored securely.
Another type of cryptography is cryptographic hash functions. This method enables “digital signatures” to authenticate who a message is from and whether a message has been altered. Hash functions output a short hash of fixed length that is unique to a message and its author. Hash functions have gone through many mutations, culminating in 2012 when NIST (National Institute of Standards and Technology) announced an algorithm from Keccak that won a competition and will thereby be the new Secure Hash Algorithm (SHA), called SHA-3.
Asymmetric cryptography is a method that enables two parties to secretly agree on a shared encryption key. Since proposed in a paper from Whitfield Diffie and Martin Helman in 1976, the idea of cryptography using “public and private mathematically related keys”, also called asymmetric, has been become widely popular, especially in online communications. Asymmetric cryptography uses two keys. One key is shared publically between users to use for encryption, while the other key is kept private to use for decryption. A public key is derived from a private key in such a way that that the private key can decrypt data encrypted from a related public key, but not vice versa. No information about a private key can be derived from a public key.
The trade-offs for asymmetric methods include a chief advantage of asymmetric cryptography that includes the reduction in the number of unique secret keys that have to be shared between users requesting to communicate. Disadvantages of this method include computational cost, slow speed, and the possibility for widespread compromise if a single private key is compromised. Additionally, data may be irretrievable if a private key is lost. In addition, asymmetric encryption is far more susceptible to brute force attacks than symmetric encryption. For example, AES 256 is as strong as 15,360-bit methods using asymmetric encryption such as RSA (Rivest-Shamir-Adleman). Last and possibly most challenging is that the lack of authentication of public keys leaves the real possibility for man-in-the-middle attacks where a third party can impersonate an intended recipient by intercepting a sender's public key and exchange his or her own credentials with the sender without either the intended recipient nor the sender's knowledge.
Trusted 3rd Parties (Certificate Authorities) such as PKI (Public Key Infrastructure) and PGP (Pretty Good Privacy) are examples of asymmetric methods of encryption that rely upon some “trusted” authority to establish trust between peers over open communications such as the internet. These certificate authorities issue certificates that contain a public key of an entity and a cryptographic signature of the issuer, which is then passed to an intended recipient as evidence “they are who they say they are” (i.e. their “identity”). PGP and PKI differ in how they establish “trust.” PKI is based upon predetermined “trusted” certificate authorities (CA) while PGP is based on a “web of trust” that allows users to choose who they trust.
Trade-offs for Certificate Authorities in a similar fashion to symmetric and asymmetric cryptography, include the fact that certificate authorities are vulnerable to man-in-the-middle attacks. If a certificate authority is compromised, another party can cause false certificates to be issued to impersonate another entity. For instance, in July 2012, NIST issued a warning that theft of certificates would allow attackers to issue new “valid” certificates and/or “sign” malware. Although 3rd party certificate authorities may add security in some circumstances, credibility of this method is diminished when reports of compromise surface. New methods such as certificate pinning causes man-in-the-middle attacks to be more difficult, but it can still be bypassed in many ways. Under this architecture, if the certificates are compromised, likely so are all sessions that utilize the certificates and their associated keys.
There are other methods to improve cryptography as a means of mutual authentication that include asymmetric/symmetric combinations, such as SSL and TLS, where symmetric private keys are shared within encryption by public keys. These methods still have the issue of a shared secret between entities. It has also been shown that a private key becomes more susceptible to disclosure the longer it is used with a public key (PKI). SSL/TLS overcomes the weaknesses of authentication with PKI by using Certificate Authorities to certify the identity of a server or entity, and then overcomes the weaknesses of the speed computational expense of PKI by negotiating a temporary symmetric key for rapid encryption and decryption during a communication session. This approach places emphasis on signature process with certification authorities, which also has weaknesses as previously discussed.
Regardless of the cryptographic method used for encryption or authentication, an approach that ensures entities “are who they say they are” is needed for various scenarios, for example, where a device falls into the hands of an unauthorized user. For such instances, methods such as biometrics have been promoted.
The use of biometrics exists and entails the same principle of key management for encryption which also holds true for authentication. Authenticating methods that validate “you are who you say you are” typically utilize biometric features that uniquely identify an individual from any other individual. Unfortunately, like encryption keys, a biometric key is just another key that, if compromised, may provide a false sense of security. Furthermore, many implementations send biometric data along with other keys to authentication servers, traversing communication paths with limited security, leave the biometric sample open to interception. In addition, the widespread collection of biometric templates by governments and private companies alike, both whose custodianship has been brought into question as of late, further increases the chances of unauthorized access. Again, the same principle for exchanging encryption keys applies to exchange of authentication keys: Find the key, and unlock the door.
One approach that improves authentication is multi-factor authentication (MFA). MFA requires 2 or more factors to authenticate. Authentication factors generally consist of:
Knowledge—“something you know”
Possession—“something you have”
Biometrics—“someone you are”
Knowledge factors include passwords (secret words or phrases), PIN (personal identification number), and patterns (sequence(s) of cells). Possession factors include tokens (FOB, USB, contactless RFID, and the like), smart cards, etc. Biometric factors are typical biometric identifiers such as finger, face, voice and IRIS, among others.
Which cryptographic authentication and encryption method is more secure is the subject of much debate. Regardless of the encryption method, the issue with encryption is that the keys still must be protected. Compromise of a private key, though unlikely, could prove catastrophic. Whether disclosure is a result of flawed implementations or a flawed protocol or architecture, recent disclosures of private data bring into focus the need for some new approaches to guarantee authenticity and place control of data into the hands of the user to control the entity's secrets, keys, and private data.